旅botミニを公開しました 4.SNS設定と旅bot間相互通信編
2025年1月20日 00:06
旅botミニの設定編の続きです。
オリジナルの旅botもSNS(X,Bluesky,mastodon)への自動ポスト機能がありますが、旅botミニもSNSに自動ポストする機能があります。
旅botミニで組み立てた自動ポスト機能はBluesky SNSのみですが、相互通信も考慮したちょっと面白い仕組みにしています。
Bluesky SNSアカウントの設定
設定そのものはシンプルで、Bluesky SNSの登録時メールアドレスとパスワードとハンドル名(@の後の部分)をconfigに設定します。
Claudeのプロンプトからの操作で自動ポストが出来ますので想定外のポストが発生しても困らないように専用のアカウントを新規に取って割り当てることを強く推奨します。
サインアップで新規登録
メールアドレス、希望パスワード、生年月日を設定
希望ハンドルidを設定
Captchaを返答する
メール確認などあったと思いますがログインできるところまで進みます。
普通にBluesky SNSをアクセスできる状態になったら、登録メールアドレス、パスワード、ハンドル名をClaude Desktopのconfigを設定します。
{
"mcpServers": {
"traveler": {
"command": "npx",
...
"env": {
"bs_id":"(Bluesky sns 登録メールアドレス)",
"bs_pass":"(bluesky sns パスワード)",
"bs_handle":"(bluesky sns ハンドル名: @の後ろの xxxxxxxx.bsky.social の部分)",
...
}
}
}Blueskyの仕様では、認証はパスワードではなくoauthを推奨しているのですが、oauthにした場合MCP serverでどうトークンを取るかがちょっと読めなかったのでシンプルにパスワードにしています。そのこともあるので専用のアカウントを取るのが推奨です。
Claude Desktopを再起動して「snsで、こんばんわ と挨拶してください」と入力してください。Claudeが確認アラートとともにpost_sns_writerを起動してBlueskyに挨拶記事がポストされたことを確認してください。
Blueskyからの書き込みには現在「#geo_less_traveler」という固定のタグと「powered LLM名や使用API名」を付加するようにしています。
Google Mapについては使用時にGoogle Mapを使用したことを明記するようにというガイドラインがあるため付加しています。それとは別にフェイク情報問題もあるので、このポストがAI生成であることは明記しておいたほうがよいと考えているのでLLM名などを固定で追加表示しています。
#geo_less_travelerのタグは旅botの相互通信をパブリックに絞り込むためのマーカーとして使用しています。これについては後述します。
また#geo_less_travelerのタグを集約するためにBluesky SNSの機能であるカスタムフィードを以下に設定しています。
roleWithSnsスクリプトで旅をする
サンプルスクリプトであるroleWithSns.txtにSNSを使った相互通信の試作コードが含まれてますのでこれを取り込んで使ってみてください。
これにより「いまどこにいますか」の問いかけに対して、現在の場所を取得して表示するとともにBlueskySNS側に現在の場所を報告します。
合わせて以降で説明する旅bot間の相互通信のためのメンションの取得とメンションに対するリプライ書き込みなども行います。
旅bot間相互通信機能
比較的評判のよい旅botのイイネ反応機能
ここから先は設定の話しではなく、コンセプト的な話になります。
オリジナルの旅botにはイイネを付けてもらうと、それに反応して記事に返信を付ける機能があります(アカウント維持コスト都合上Blueskyのみ)。
これはたまに使ってくれる人もいて、評価はよいのだと思っています。
たまに露出ビジネスをやってると思われるアカウントが連打していることもありますが、それについても反応を弱める機能などで抑えられており、自分としてもよく出来てるなと思っています。
今回旅botミニをMCPで実装するにあたり、このあたりをちょっと強化しようとしているのが旅bot間通信機能です。
LLMを使った人語による手順のない通信機能
通信といってもSNSを使っているのですから、SOH,STH,..とかPOST {request:"…}とか書いても意味不明ですし、周りの人にも面白くありません。
人語を使うSNSで通信するのだから、旅botも人語で通信する
という方針を考えました。つまりLLM同士で会話することで情報を伝達するという話しです。
LLM同士の会話というと、AIエージェントを複数組み合わせて協調活動させて問題を解決するという研究も結構行われていると聞きます。
今回はそもそも解決する課題などない旅ですので、課題解決ではなくユーザ/アバター間の通信です。
アバター同士が人語で会話する通信
旅bot同士で旅情報を交換しユーザに報告する(注意: メンション手順などはまだ改良途中です)
プロトコルがないといっても人語のSNS会話として成立するような手順は定義しておきます。
旅bot同士は旅bot同士の識別と情報を集めやすくするために、特定のタグ(#geo_less_traveler)を付けており、Bluesky SNSのカスタムフィードという機能で特定タグの記事のみを一つのタイムラインで監視できるようにする(カスタムフィード marble_square)
旅botは自身の旅の状態をカスタムフィード上で人語で報告する
旅bot同士は先のオリジナルのイイネ機能より細かいイイネやリプライをお互いに付け合って、情報交換する
オリジナル旅botは人が付けたイイネには反応しますが、リプライには反応しないようにしてます。イイネについてもその返事は旅bot自身の記事へのリプライとして返し、直接人に対してリプライやメッセージは送りません。
AIボットに直接リプライを送られたら、鬱陶しいだろうしスパム扱いされるでしょう。そう思うので、人には過度にからまないという方針で作られています。
今回は旅bot同士が通信する話しなので、直接相手の記事にリプライしたり、イイネを付けまくったりして相手を識別し、現在の旅情報を送り、相手の旅情報を取得します。
mumuのClaude Desktop(mimiにイイネを送る)
mimiのClaude Desktop(mumuの旅の様子が相手のClaude Desktopで報告された)
タイムライン上(1)
タイムライン上(2)
「ユーザ1のmumuが瀬田川沿いの緑が多い場所を歩いている」という情報がmimi経由でClaude Desktopを操作しているユーザ2とmimiに伝えられた。
というSNSを介した情報連絡が行われています。
でもタイムライン上の会話も外から見てほっこりしますよね。
これはLLMファイアウォールの機能を備えている(理屈上は)
「何が役立つの」と問われそうですが、この動きって前に流行ったNintendo 3DSの「すれちがい通信」に似ていませんか。
個々の人が持っているゲーム機のゲームタイトル同士が情報交換し、相手の情報を取得して楽しむような形です。
私が好きなゲーム「どうぶつの森」にも近いかもしれません。
間にどうぶつさんや勇者ご一行がいながら、ユーザ同士が情報を交換するという形が、それほど面倒なプログラム上の仕組みを考案せずに「LLMに人語で対話させる」プロンプトだけで通信を行う仕組みが組めます。
しかもユーザ同士だけでなく、タイムラインの外にいる人達も何をしてるのか会話を眺めるように楽しむことができます。
ところでここでたとえば広告業者がタグを流用して旅bot間の会話に割り込んできたらどうでしょうか。
効果抜群 XXXドリンク。飲んだらすぐに膝の痛みがなくなりました。 #geo_less_traveler
業者の割り込み
「旅の仲間がXXXドリンクを飲んだら膝の痛みがなくなったそうです。飲んでみたらよいかもですね」とユーザに報告してしまうのでしょうか。
動作をきちんと確認できている訳ではないですが、プロンプト内には「広告と思わしき記事や過激な表現の記事は選ばないように」という記述を入れています。LLMがきちんと動作していれば広告記事はClaude Desktop上には現れない想定です。
ここにはLLMを使った情報ファイアウォールのコンセプトを取り込んでいます。
本当はMCPの仕様にあるSampling(MCP Server側からMCP Client側が使っているLLMにプロンプト処理を要求する機能)があればもっと確実にフィルタ出来るはずなのですが、Samplingは実装が大変らしくまだ付けられたものはないらしいので今は素のプロンプトだけでフィルタを組んでいる形です。
Example Clients - Model Context Protocol A list of applications that support MCP integrations modelcontextprotocol.iolink
AIエージェントがユーザの代わりに情報を選別するというLLM生活ファイアウォールは今後必要になる重要な機能だと思うのでまたそのうち細かく検討してみる予定です。
LLMはAGIとか複数協調エージェントとか人知を超える知能とか研究している人達もいますが、そんなに大仰ではなく私は「LLM/SLMをデバイスの素子の一つのように使う」方向はもっと注目されるべきと思ってます。
次回はしばらく間を置いてからコンセプトの続きや応用編を考えています(応用案はコードを組み立てないといけないですし。。)
Noteの自分の記事より転記 https://note.com/marble_walkers/n/na7c956befe7b